home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 1⁄5⁄90 / 0292-Re view initializati-Jan90 < prev    next >
Encoding:
Text File  |  1990-01-02  |  4.1 KB  |  85 lines  |  [TEXT/GEOL]
  1. Item    5809610                         2-Jan-90        11:29
  2.  
  3. From:   LAI1                            Lai, Edmund
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Re: view initialization
  8.  
  9. James Plamondon wrote:
  10.  
  11. *****
  12. If a view needs to contain an explicit reference to another view, the
  13. reference often cannot be initialized during IRes(), because the view being
  14. referenced may not have been created yet.  Only those views preceding a given
  15. view in an in-order traversal of the view hierarchy have been created when
  16. IRes() is called on the given view.  A call to FindSubView() will fail if the
  17. view being sought has not yet been created.
  18.  
  19. If the distinction between creation and initialization were made, this would
  20. not be a problem.  First, the tree would be traversed, creating all of the
  21. specified views.  Once all were created, then the tree would be traversed
  22. again, allowing each specified view to initialize itself.  Since all of the
  23. views in the hierarchy would exist during the initialization phase, all calls
  24. to FindSubView() would work properly.
  25. *****
  26.  
  27. There are a number of responding links indicating that this is not an isolated
  28. problem and wishes for a solution in post 2.0 MACAPP. However does the
  29. distinction between creation and initialization of view completely solves the
  30. problem? It all depends on what explicit reference to another subview means. If
  31. it means something like
  32.  
  33. subViewX := FindSubView(id1);
  34. fSubViewX := subViewX;
  35.  
  36. then this would work.
  37.  
  38. But if what you are trying to do during initialization is
  39.  
  40. subViewX := FindSubView(id1);
  41. FailNil(subViewX);
  42. subViewX.doABC;
  43. subViewX := FindSubView(id2);
  44. FailNil(subViewX);
  45. subViewX.doXYZ;
  46.  
  47. then this is no better since when you try to doABC or doXYZ, even though
  48. subViewX points to an ojbect, that object is not initialized. This indicates we
  49. need a more radical solution to the problem. However James also indicated the
  50. general response is that people are unwilling to change even for his less
  51. radical solution, then why would people be willing to accept a more radical
  52. solution. I think that depends on whether the more radical solution can solve a
  53. much wider classes of problem, then maybe people may be more willing to accept
  54. it.
  55.  
  56. Let us step back a little bit and see what 'view' resources really do. A MACAPP
  57. TView is really a network of objects, by which I mean a group of objects that
  58. have object reference to each other. A 'view' resource is really a flat
  59. representation of the network in which there is no direct object reference in
  60. memory so that it can be stored permanently into the disk. The process of
  61. reading from a template is really to restore the network of objects with all
  62. the memory object references from its persistent state. In other words the
  63. 'view' resource and the IRes, WRes are really a mechanism for persistent
  64. objects. Of course this is not general persistent objects since it is
  65. restricted to TView objects and its subclasses. Because of this restriction the
  66. MACAPP view template implementation makes uses of the assumption that views are
  67. hierarchical, superviews are created before their subviews etc. While this
  68. simplifies the implementation, it makes it impossible to use the same
  69. implementation for persistent state of arbitrary network of objects where the
  70. object references are usually not hierarchical. And now we find out even for
  71. views there are cases where such assumptions is making life difficult for us.
  72.  
  73. If we can come up with a general persistent object scheme for an arbitrary
  74. network of objects (this can be done, but I am not going into the details),
  75. then we have solved the view problem (since views can be considered to be a
  76. special case of the general scheme). We would also be solving problems in many
  77. other areas. The documents in the DrawShape program can now be just the
  78. persistent state of the shapes object. Network of objects can now be exported
  79. to the clipboard or through IPC to go to another application (Imagine coping a
  80. view to ViewEdit, edit it and then paste it back). To do all these it will be
  81. necessary to modify your IRes and WRes routines somewhat, but I think the
  82. additional benefits would make it worthwhile.
  83.  
  84.  
  85.